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REMARKS/ARGUMENTS 

Claims 1-53 are pending in this application. Claims 1,17, 28, 32, 36, and 45 are 
currently amended, and such amendments are fully supported by the specification and drawings 
at least at page 17, line 16-page 18, line 2, and Figure 6. For at least the reasons set forth below, 
Applicants assert that all claims are in condition for allowance. 

Applicants thank the Examiner for the telephonic interview of 9/6/2005 and the follow-up 
telephonic interview of 9/7/2005, wherein the present application and Application Serial No. 
09/783,660 were discussed. In the interview of 9/6/2005, Applicants' representative discussed 
the Simonoff reference with Examiner. It appeared that Applicants' argument regarding the non- 
anticipation of the claims by the Simonoff reference were persuasive to Examiner, particularly 
the argument that the reference failed to teach the recited component, "skeletal UI". However, 
on 9/7/2005 Examiner contacted Applicants' representative again and provided a new reference, 
U.S. Patent No. 5,347,632 (the "Filepp" reference), which Examiner asserted teaches the 
"skeletal UL" 

Double Patenting Rejection 

Claims 1-53 are rejected under the judicially created doctrine of obviousness-type double 
patenting as being unpatentable over claims 1-3, 5-6, 10-18, 46-47, 19-20, 29-31, 33-34, 36, 38, 
and 45 of U.S. Patent Application No. 09/783,660 in view of Simonoff et al, U.S. Pat. No. 
6,078,322. A terminal disclaimer in compliance with 37 C.F.R. § 1.321(c) is filed herewith to 
overcome the nonstatutory double patenting rejection, thereby obviating this rejection. 

Rejection Under 35 US.C. $ 102 

Claims 1-3, 5-6, 7, 8-12, 14-19, 21-22, 23, 24-47, 48, 49-53 were rejected under 35 
U.S.C. § 102(e) as being anticipated by Simonoff et al. U.S. 6,078,322. As set forth in more 
detail in the previous amendment and during the aforementioned telephonic interviews, the 
reference fails to describe every element of every claim as required by MPEP § 2131, and 
therefore the rejection is unsupported by the art. To the extent Examiner was not persuaded 
during the interviews that Simonoff failed to anticipate the pending claims, Applicants address 
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the Simonoff reference below and Applicants have amended the claims to clarify the "skeletal 
UI" as requested by examiner. To the extent that Examiner was convinced that the Simonoff 
reference does not teach at least the "skeletal UI" but believes the Filepp reference teaches this 
limitation, the Filepp reference is also addressed below. For at least the reasons stated below, 
Applicants respectfully request that the rejection be withdrawn. 

Simonoff Reference 

Independent claims 1, 32, and 36 recite "supplementing a skeletal UI. . .with one or more 
icons, labels or menu items, or combinations thereof." The Simonoff reference fails to disclose 
this limitation. Simonoff describes a Universal Client device that is downloaded to the client host 
300, which in turn loads and interprets a GUIScript file, and then displays an appropriate GUI to 
the user. Col. 8, line 66-Col. 9, line 4; Col. 9, lines 34-38. However, there is no indication in the 
reference that the GUIScript file or the GUI is anything less than an entire UI displayed to a user. 
Nowhere does Simonoff describe a "skeletal UI," much less supplementing a "skeletal UI" with 
icons, labels, or menu items as claimed. Because the reference does not teach or suggest a 
skeletal UI as claimed, the rejection fails to establish a valid § 102 rejection, which requires that 
a reference teach every element of every claim . See MPEP § 2131. 

In response, Examiner argued: 

...Simonoff teaches the above limitations. See for example, Col. 
12, lines 24-60, wherein the GUIScripts carries a GUI change in 
response to an event, the event, i.e. button clicking, has resulted in 
partial GUI updating, only a portion of the GUI are generated at a 
time, any additional changes applies to the existing GUI are based 
upon system events, thus, GUI elements are supplemented in 
accordance with client requests, (see also, Col. 11, lines 55-67; 
Col. 12, lines 40-45). 

Office Action, 6/17/2005, p. 22-23, ^ 54. However, as explained by Applicants 5 representative 
in the telephonic interview of 9/6/2005, this teaching of Simonoff does not anticipate the 
"skeletal UI." Specifically, the operating steps of the system of Simonoff cited by Examiner and 
described at Col. 12, lines 24-60 and Fig. 5, describe changing a GUI by indiscriminately 
refreshing the entire GUI based on a GUIScript message. See Col. 12, lines 49-53 ("The second 
GUIScript message is. . .used by the Universal Client device in generating a refreshed GUI 
during step 14"); see also, Fig. 5, step 14 ("refresh GUI"). There is no indication that any 
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component or element described in Simonoff is skeletal, and there is no indication that such a 
component or element is supplemented much less that is supplemented " with one or more icons, 
labels or menu items " as claimed. 

Moreover, Examiner's argument rests on the assumption that when an application in the 
Simonoff system performs an operation, "GUIScripts carries a GUI change" and "only a portion 
of the GUI are generated at a time." However, Simonoff describes only that an application 
message may include "information denoting a change in the appearance of the GUI displayed on 
the client host 300." Col. 12, lines 40-45. Interpreting this passage as teaching that the 
GUIScript message contains only changes to the GUI definition — rather than an entire GUI 
definition with changes — is contrary to the reference as a whole, which teaches that the 
GUIScript file "defines all the display windows and their operation for the application running 
on the application host 200" and is usable to "display the appropriate GUI to the user." Col. 9, 
lines 33-50. (emphasis added). See MPEP § 2141.03 (VI)("A prior art reference must be 
considered in its entirety, i.e., as a whole, including portions that would lead away from the 
claimed invention .") 

Additionally, Examiner's argument is further made moot by the amendments to the 
independent claims, which inter alia clarify the "skeletal UI" as requested by Examiner during 
the interview. Specifically, claims 1, 32, and 36 now recite that "the skeletal UI specifies a 
layout of the client-resident intermediate UI including respective locations of the one or more 
icons, labels or menu items, or combinations thereof," and claims 17 and 45 recite "the UI form 
definition includes a list of controls and respective locations of the controls as rendered on the 
client device, the controls being UI objects provided by the client device operating system or 
other client-resident application." Claims 1, 32, and 36 further recite "the skeletal UI and the 
one or more icons, labels, and menu items being independently updateable from one another," 
and claims 17 and 45 recite "the UI form definition and the controls being independently 
updateable from one another." Simonoff clearly fails to teach any skeletal UI or form definition 
element that achieves all of these limitations. 

For at least these reasons, the Simonoff reference does not describe such GUI objects as 
being skeletal nor supplementing the same. 
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Filepp Reference 

During the interview on 9/7/2005, Examiner identified the Filepp reference, U.S. Patent 
No. 5,347,632. It was not specified precisely how this reference was to be applied (e.g., part of a 
35 U.S.C. § 102 or 35 U.S.C. § 103 rejection), but this reference neither teaches all of the recited 
claim limitations nor is it properly combinable with the Simonoff reference. 

With respect to combinability, Filepp may not properly be combined to anticipate the 
claims because the reference teaches away from the operation of the present claimed invention. 
See MPEP § 2145 ("A prior art reference that 'teaches away' from the claimed invention is a 
significant factor to be considered in determining obviousness. . .") Specifically, the present 
invention is directed towards a thin client architecture, where substantial proportions of the 
processing are performed server-side to reduce the load on the client . See claims 1, 17, 32 36, 
and 45; see, also, Spec. p. 6, lines 19-21 ("A preferred embodiment of the present invention 
provides a data communication architecture that exhibits the following attributes: a relatively 
thin client for reduced client-side resource demands . . .") (emphasis added) In stark contrast, 
Filepp is directed towards an architecture that reduces the load on the server and provides for a 
fat client: 

...the invention includes procedures for formulating objects that 
have been specially structured to include display data, control data 
and program instructions for supporting the applications at the 
network reception systems, the objects being pre-created, parceled 
units of information that may be distributed and stored at lower 
levels in the network ... so as to reduce processing demand on the 
network higher element . . . 

Col. 2, line 60-Col. 3, line 1 (emphasis added); see, also Col. 76, lines 37-47 ("the table can be 

presented to the user's RS 400, where the [client-side] RS 400 can provide the data processing 

required to present the potentially relevant keywords, objects and associated applications to the 

user. . . this procedure reduces demand on server . . see, also Col. 1, lines 16-25 ("This 

invention relates generally to a distributed processing. . .computer network in which the 

interactive text/graphic sessions are comprised of pre-created blocks of data and program 

instructions which may be distributed downwardly in the network for use at a software enhanced 

user computer terminal that reduces processing demand on the higher-level network 

elements . . ."); see, also Col. 75, lines 41-56 ("the method aspect of the invention includes an 
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improved procedure for searching and retrieving applications from the store of applications 
distributed throughout network. . . this reduces the demand on the server . . ."). 

Accordingly, considering the Filepp reference "in its entirety, i.e., as a whole , including 
portions that would lead away from the claimed invention/' one skilled in the art would not 
reasonably combine Filepp with Simonoff, or any other reference, to teach or suggest the 
limitations of the present claimed invention. MPEP § 2141.03 (VI). Moreover, the teachings of 
Filepp may not be considered in a vacuum with improper hindsight reasoning; as the Federal 
Circuit noted: 

It is impermissible within the framework of section 103 to pick and 
choose from any one reference only so much of it as will support a 
given position, to the exclusion of other parts necessary to the full 
appreciation of what such reference fairly suggests to one of 
ordinary skill in the art. 

In re Hedges, 783 F.2d 1038, 1041, 228 U.S.P.Q. 685, 687 (Fed.Cir.1986). For at least this 

reason, Filepp is not properly combinable to create a valid 35 U.S.C. § 103 rejection. 

In addition, the Filepp reference fails to disclose every claim limitation, and in particular 
the reference fails to teach or suggest at least the "skeletal UI" limitation. For example, 
independent claims 1, 32, and 36 recite generating or rendering a user interface including the 
step of "supplementing a skeletal UI. . .with one or more icons, labels or menu items, or 
combinations thereof." In contrast, Filepp does not "supplement" a skeletal UI, but rather the 
architecture of Filepp formulates "objects that have been specially structured to include display 
data, control data and program instructions for supporting the applications at the network 
reception systems, the objects being pre-created, parceled units of information that may be 
distributed and stored at lower levels in the network; e.g., at the [client-side] reception system." 
Col. 2, lines 60-68. In other words, the displays of Filepp are defined by pre-created , predefined 
objects that already include display data, control data, and program instructions. The plan views 
shown in Figures 3a and 3b show page partitions (Fig. 3a) and display fields (Fig. 3b), but these 
are not "icons, labels, or menu items" as claimed. Nowhere does Filepp describe these objects 
being created by supplementing a skeletal UI. 
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Moreover, the architecture and operation of Filepp fail to teach other claim limitations 
and generally teach away from the present invention for a variety of additional reasons. Because 
Applicants have not yet been provided a with reasoned rejection incorporating the Filepp 
reference, a sampling of these additional shortcomings of the reference are provided here. For 
example, independent claims 1 and 32, and dependent claims 44 and 53, recite a UI format and 
UI form definition that are " based upon a number of device capabilities for a client device /' and 
independent claim 17 recites a UI form definition that is " dictated by a number of device 
capabilities for said client device ," Filepp fails to teach these limitations, and instead discloses 
display objects that contain "information about what is to be displayed and how it is to be 
displayed," but nowhere does the reference teach or suggest that these objects are "based upon" 
or "dictated by" client device capabilities as claimed. See, e.g., Col. 7, lines 24-46 and Col. 7, 
line 64-Col. 8, line 39 (describing the objects of Filepp without any indication of correspondence 
to client device capabilities). Claims 1, 32, 36, and 45 of the present invention also recite 
populating or rendering a native UI control of the UI on the client device with data items, and 
dependent claim 28 recites storing a UI form definition, including at least one native control that 
is stored locally at the client device. Filepp also fails to teach these limitations, and instead 
discloses pre-created objects with display data that are sent to the client device, not native objects 
as claimed. Col. 2, lines 60-68. 

For at least these reasons, the Filepp reference neither teaches all of the recited claim 
limitations nor is it properly combinable with the Simonoff reference. 

Rejection under 35 U.S.C. $ 103 

Claim 13 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Simonoff in 
view of 'Official Notice'. Neither Simonoff nor the Official Notice, nor the combination thereof, 
teach or suggest all of the limitations of claim 18. Claim 18 is allowable as being dependent 
from claim 1 for the reasons set forth above. 

Claims 4 and 20 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Simonoff et al. US 6,078,322 in view of "Browser wars: Rest in peace," Patrick, January 2001. 
Included with this response is a 37 CFR § 1.131 declaration, swearing back of the Patrick 
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reference. This declaration is seasonably presented in accordance with MPEP § 715.09 and 
effectively antedates the Patrick reference in accordance with MPEP § 715. Thus, the 35 U.S.C. 
§ 103 rejection is now moot. 

This application now stands in allowable form and reconsideration and allowance is 
respectfully requested. 



Respectfully submitted, 



DORSEY & WHITNEY LLP 
Customer Number 25763 
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